Software defined networking to support the software defined environment

ions provide new tools to enable the richer networking functionalities demanded by recent industry trends including dynamic virtual server workloads, multi-tenant cloud computing, and warehouse-scale data centers. Existing standards and abstractions have proven inadequate for delivering this functionality Bat scale[; for example, 12-bit virtual local area network (VLAN) identifiers [2] allow for up to 4,096 isolated tenants. To address this, networks have become increasingly complex, including proprietary routing, traffic engineering mechanisms, and labor-intensive configuration of network appliances used to secure and optimize multi-tier systems. SDN offers the potential to reverse this trend by addressing these problems in the controller software running on commodity servers that programs network hardware using open protocols. The dominant use of SDN that enables solutions to these problems is network virtualization. Network virtualization involves abstracting the physical network in two ways: (i) isolating multiple tenants and giving them a Bview[ such that they are the only ones using the network and (ii) presenting an abstract topology that may differ from the physical topology, e.g., an abstract topology with all hosts attached to a single, large switch. A related concept is Network Functions Virtualization (NFV) [3], which replaces specialized appliances such as firewalls, load balancers, and intrusion detection systems with virtual machines (VMs) running on conventional servers [4–7] connected to the network. In the server world, virtualization has enabled new applications and revenue streams that would not have been technically possible or economically feasible otherwise. It is anticipated the same will be true for networking. Splitting the data plane and the control plane In conventional networks, each device implements both data and control plane functionality. For example, when a packet is received at a switch, the data plane matches fields in the packet with respect to forwarding rules and performs specified actions such as changing the destination Internet Protocol (IP) address and forwarding the packet on a specific port. To instantiate these rules, various mechanisms are used. For basic forwarding, each device participates in distributed control plane logic, communicating with peers using protocols such as spanning tree [8] or Transparent Interconnection of Lots of Links (TRILL) [9] for Ethernet switchesVand Border Gateway Protocol (BGP) [10] or Open Shortest Path First (OSPF) [11] for IP routers. SDN combines these control channels into one mechanism that can control both basic forwarding and more sophisticated services. Each device continues to forward packets at full speed on the basis of currently installed forwarding rules, but the distributed control plane is replaced with a logically centralized controller that programs the forwarding rules of each device in the network. The controller uses its global network view to create basic forwarding rules that are not Figure 3 The underlying network implementing the abstract network shown in Figure 2. The thick arrows represent the tunnels that provide the abstract connectivity from the Internet to the various services via the appropriate middleboxes. The hypervisor virtual switches (labeled vSwitch) are responsible for routing traffic in to and out of the tunnels. The quality of service requirements between the application servers and database servers are provided by configuration in the switches and are not shown. C. DIXON ET AL. 3 : 3 IBM J. RES. & DEV. VOL. 58 NO. 2/3 PAPER 3 MARCH/MAY 2014 limited to spanning trees and dovetail with higher-level functionalities such as Network Address Translation (NAT) and VLANs. The ability to control all aspects of the network results in flexibility and innovation. Centralizing network control Once the data and control planes are split, it is no longer necessary to have a distributed control plane. As a consequence most realizations of SDN migrate a substantial portion of network control functionality to a logically centralized SDN controller. The controller connects to every switch in the network, typically through a separate control network, which allows it to monitor and control each device. A tightly coupled cluster of SDN controllers can be used for scale-out and fault-tolerance [12–14]. In such clusters, consistently distributing shared state can be problematic and many recent efforts have explicitly distributed some tasks either to a subset of the cluster or to switches to alleviate these issues [15, 16]. Though less common, the distributed management plane can also be replaced with a logically centralized management point, possibly the same controller, to enable network-wide monitoring, management, and policy enforcement [17]. While there are well-recognized trade-offs between distributed and centralized control, the advantages of centralization appear to greatly outweigh the disadvantages in the context of SDN. Most of the problems described earlier can be solved using SDN technology. For example, an SDN controller has global visibility into the current state of the network, e.g., link and buffer utilization, device failures, and where hosts are located, so it can implement end-to-end quality of service (QoS) and respond rapidly to failures [18, 19]. However, SDN need not centralize control entirely. Internet scale networks and networks of large organizations will continue to consist of numerous independent administrative domains. The rest of this paper is organized as follows. The next section describes several example SDN scenarios: network virtualization and abstraction, middlebox connectivity, fabrics, monitoring-control loops, and QoS. That is followed by a discussion of IBM’s SDN vision and offerings including the OpenDaylight** Project [20]. After that, examples of early adopters of SDN technology are presented. Two final sections briefly discuss migration to SDN technology and provide concluding remarks. Example SDN scenarios SDN provides a platform on which a wide variety of scenarios can be realized. Ultimately, the functionality delivered via this platform will be limited only by developers’ ingenuity and imagination. Here, we describe six scenarios that have already been realized: network virtualization, network abstraction, middlebox insertion, fabrics, monitoring-control loops, and QoS. These examples are chosen to both give an idea of the breadth of SDN’s uses and illustrate some of the most prevalent current